* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Pim Status Pages

Protocols for IP Multicast (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 1998-Jul-28 —  
Chairs
 
 


IETF-102 pim minutes

Session 2018-07-17 1550-1820: Notre Dame - Audio stream - pim chatroom

Minutes

minutes-102-pim-01 minutes



          PIM WG notes
          
          draft-ietf-pim-multiple-upstreams-reqs:
          Carlos: Author to update document and upload new revision which would
          address AD comments.
          
          draft-ietf-pim-msdp-yang:
          There was no response in WGLC.
          There would be 2nd WGLC.
          
          draft-ietf-pim-explicit-tracking-13:
          Hitoshi: AD need some implementation detail, since document is
          experimental it need to have some more detail. Author is considering it
          to change it to informational document. AD has some concern over document
          so Author need input from vendor about implementation.
          Mike: Will draft be in hold for now?
          Hitoshi: Yes.
          Action Item: WG need to provide some help to author, to get implementation
          detail to move forward.
          
          draft-ietf-pim-igmp-mld-snooping-yang-03
          Updated new version, 03. It was accordance with rfc6087
          New update is expected with comment from Yang doctors.
          Robustness variable range got changed.
          Added example of instance data tree with JSON encoding.
          Requesting WGLC.
          
          draft-ietf-pim-igmp-mld-yang:
          Waiting for AD eval.
          Mike: to Alvaro, if Yang data model been reviewed.
          Alvaro: He would review the draft.
          
          PIM with IPv4 prefix over IPv6 NH:
          Presented 2 IETF back. It got adopted as WG document
          Author thinks it is ready for WGLC.
          3 in room support none against.
          WGLC to be done in list.
          
          pim-reserved-bits:
          It is intended to update PIM RFC to make sure bits are not marked as
          available in PIM RFC .
          Extending Type space
          Discussions:
          Andrew: Do we need to solve this problem?  We think right now there is
          no need.
          Toerless: We can procrastinate it for some time.
          Ravinder : No need to update now
          Alvaro: If we adopt, we do not need to publish. We can change the document
          as per need. So even if we publish this document, it would have no impact
          on existing implementation.
          Toerless: You can let it expire and bring it up when there is really
          need.
          Dave Allen: Is there some way to change IANA policy?
          Alvaro: 4601 / 7761 does not say how to assign bits. Another RFC took
          it. If some other WG assigns the document, we have no way to block it.
          Since we do not have allocation policy, we can potentially allocate the
          space.
          Donald: You can have Ack to check if implementation supports new type?
          Stig: New hello options can be added to check if Extended type is
          supported.
          Action Item: Mike to check interest in list.
          
          p2mp-BFD:
          Presented in London.
          BFD to use to monitor health of DR
          There was discussion in list, and draft was updated based on feedback.
          It would be good to monitor DR and BDR
          Suggestion is to be used for PIM Assert too.
          Stig: There are several implementations already.  This document does
          not require mull mesh of BFD sessions.  There is no existing document
          in PIM describing BFD uses.
          2 people are for adoption, none against. Need to take it to list for
          adoption call.
          
          Framework for multicast applied to SR-MPLS:
          Toerless: Is tree-SID proprietary?
          Hooman: Tree-SID was never discussed in IETF.  Tree-SID was discussed
          in BGP-SR TE draft.
          Mike: Since Spring is not accepting multicast related draft, it is not
          part of their charter, it is being presented in PIM which we’ve agreed
          to between the SPRING/PIM chairs.
          Toerless: State reduction is coming from tunneling?  what is the reason
          to call it as MPLS / SR ?
          Initially it started work as global SID , that was the reason it was
          named with SR
          Hooman: We need SR type of solution of multicast.  Multiple solution
          exist, should it go in single group. If there is one solution needed
          Toerless: Whether SR or MPLS ? can we have technical reason to pick one
          above other.  Author to provide more detail.
          First Presented IETF97 , Its updated new text and improvement to algorithm
          in current version.
          Jeffery Zhang:  we still have state in core, as long as there is
          replication point. It does not fit SPRING. In SPRING does not need,
          single solution for all case.  Is there really gain with this solution?
          This could be one solution, using name framework in draft is not good.
          It does not modify existing data plane solution. And this solution can
          be done with existing MPLS.
          Andrew: multicast is not easy, by the time this become standard. We might
          already have hardware which support other better solution.  Do we really
          need complex solution?
          Hoomann:  It might be complex solution and might not be useful.  It might
          need to make simple.
          Jeffrey Zhang: multicast is not in latest SPRING. Is it not related
          to SPRING.
          Alvaro: It must be part of multicast.
          Ravinder: Do not agree to use only BEIR , it would be good to have
          multiple solution.  How would it scale for high scale?
          Andrew: We cannot have multiple solution. We need to have proper
          technologies. We should have reason to have some solution.
          Action Item: WG adoption call in list.
          
          Reliable PIM Registers:
          No update since 101
          Working group adoption?
          Lenny: MSDP is not problem here, real problem is ASM. You are moving
          all the stuff from MSDP to other protocol.  Do not disagree with draft,
          but not agree with strategy.
          Toerless: MSDP works only with IPv4. It can be implemented for IPv6
          too. It would be inconsistent. So, it’s good to have new document.
          Lenny: We might still need intra domain ASM.  Should we move to new
          solution?
          
          PIM NULL Register:
          It was presented in IETF 101
          Its packs multiple NULL register in single message
          WG adoption call needed.
          
          PIM graceful insertion and removal of PIM router:
          Provides mechanism to gracefully insert and remove the PIM router in
          network.
          Jeffrey:  it has been brought up before, it can be used in more general
          place. Even for topology changes, it can be used.  Do not think signaling
          is needed.  It’s all local behavior.
          Andrew:  No signaling is needed.  It works for most of existing
          implementation.  There is other mechanism which provides 0 traffic
          loss.
          Lenny: It could be generic case.
          Toerless: There might be already existing document
          Ravinder: Need to prevent loop or duplicate traffic.
          Jeffrey: Its almost same as MOFRR.
          More discussion in list.
          
          IGMP / MLD standard status:
          Discussion to see if IGMP / MLD different version document should be
          moved as standard.
          Discussion was from MBONED .
          Alvaro : WG can do whatever looks good. Either absolute the document.
          Or change the status as Historic.   Process is status change document,
          which would explain why we are doing it.  If justification is bigger or
          there are section, then it might be actual draft which goes through all
          of the discussion.
          Andrew: if it is historic, can we still make some changes? Can it be
          changed again?
          Alvaro: Since it goes through all process, theoretically it should not
          be changed in future.
          Andrew: Some of the changes can be done quick.
          More discussion to happen over list and move forward with next step.
          
          DR load balancing:
          History of draft and current status.
          1 hand in favor of drlb none against wglc will take it to the list.
          
          Backup-DR:
          How is it diferent from pim dr improvement
          Lenny: strikes me as a narrow case. Still have failure detection
          with/without this. Just reducing join latency on one router. Only solving
          join latency on one hop. There’s MOFRR that kind of solves this problem.
          Mankamana: problem statement is the exact problem. Can we do it with
          existing hellos.
          Lenny: do we need to specify this in a wg doc more of an implementation
          issue.
          Ravinder: no real problem on SP network because its already subsecond. We
          solved this using other methods. Already other options that solve this
          problem.
          Mankamana: if its in the protocol its on a as needed basis. Some
          customers need faster convergence. You can still go with the existing
          pim dr model.
          Andrew: second Lenny. Informational draft perhaps. Shouldn’t be
          specifying. Stig: for those who don’t need it to be specified, do you
          see this as being the same for the current wg draft.
          Lenny: just seems like a small optimization for a small failure.
          Stig: we have two drafts in the same space.
          Lenny: just don’t need changes to the protocol.
          
          Graceful-dr-shutdown:
          New hello option saying going in maintenance mode.
          Lenny: confused about the assert part which is usually for a transit lan,
          they don’t usually occur on the lan with receivers. Are they pim asserts
          and why needed?
          Mankamana: yes, pim asserts. Timing for leaving and taking role. Assert
          is one of the mechanisms but open to other options.
          Lenny: why just not send a lower DR priority and the other will take
          over.
          Mankamana: that is one option. This is to avoid any traffic loss. You
          will have to give other DR the ability to form tree and start forming.
          Lenny: I set my dr priority to 0 and keep forwarding until I see someone
          else forwarding. Seems like an implementation thing. Could be specified
          for experimental. Not worth changing the protocol.
          Ravinder: receivers don’t take two copies of the mcast copies anyway.
          Stig: either you accept gap in packets or you try to make it smooth like
          this where you will get a duplicate packets or two. Have to choose one
          or the other.
          Lenny: what if he sends join to the backup dr. would that work. Then
          he can prune his branch. Financial guys have problems with duplicate
          packets.
          Lenny: lets say 110 his upstream link dies, his shortest path could be
          one of the other 3 routers.
          Stig: you still have the assert problem.
          
          



Generated from PyHt script /wg/pim/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -