The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi JL,

Please see below:

On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Rahul,
>
> Please see inline,
>
>
> > -----Message d'origine-----
> > De : Rahul Aggarwal [mailto:rahul@juniper.net]
> > Envoyé : mardi 20 juin 2006 22:47
> > À : LE ROUX Jean-Louis RD-CORE-LAN
> > Cc : mpls@ietf.org
> > Objet : Re: [mpls] TR: working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> >
> > Hi JL,
> >
> > Sorry for the delay. Please see below:
> >
> > On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> >
> > > Hi all,
> > >
> > > I transfer the below comments on this list, as it should be
> > discussed
> > > as part of last call comments.
> > >
> > > Regards,
> > >
> > > JL
> > >
> > > > -----Message d'origine-----
> > > > De : LE ROUX Jean-Louis RD-CORE-LAN
> > > > Envoyé : jeudi 25 mai 2006 14:19
> > > > À:
> > > > Objet : RE: working group last call on
> > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > > >
> > > > Hi Rahul, Dimitri, Seisho
> > > >
> > > > Thanks for the great edit job,
> > > >
> > > > Find below a set of comments on this revision 05
> > > >
> > > > Four technical points:
> > > >
> > > > 1: Section 8.1.2 Downstream notification
> > > >
> > > > The text in 8.1.2 is a bit unclear
> > > >
> > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> > > >    object(s) of a Resv message to the value, that was
> > received in the
> > > >    corresponding Path message. If the incoming Resv
> > message carries a
> > > >    Notify Request object then, the LSR MUST set the Notify node
> > > > address
> > > >    in the Notify Request object to the value, that was
> > received in the
> > > >    corresponding Path message",
> > > >
> >
> >
> > > > Which value? The sub-group originator? the notify address?
> >
> > This should be the Router ID of the transit LSR if the
> > transit LSR is merging more than one Resv with a Notify
> > Request object.
>
> Ok, but it also applies when the LSR changes the sub-group originator id
>to its own address doesn't it?
>

Yes, you are right.

> >
> > > > This is unclear.  The processing needs to be clarified.
> > > > We could update as follows:
> > > >
> > > > "If the incoming Resv message carries a Notify Request
> > object then,
> > > > 		-If the sub-group originator ID is its own
> > address, the LSR MUST
> > > > set the Notify node address in the Notify Request object
> > to its own
> > > > address, in the Resv message that it sends upstream.
> > > > 	    -If the sub group originator ID is not its own
> > address, the LSR
> > > > MUST propagate the Notify Request object unchanged, in the Resv
> > > > message that it sends upstream."
> > > >
> >
> > Shouldn't the transit LSR always set its own address in the
> > Notify Request if it is merging multiple Resvs with Notify
> > Request objects into a single Resv ? The current text is not
> > clear on this either.
>
> A transit LSR should actually put its own address in the Notify Request not only when it is merging multiple Resv, but also when it changes the sub-group orignator id to its own address (even if there is no Resv merging)
>
> >
> > How about:
> >
> > "A transit LSR sets the Sub-Group Originator ID in the
> > FILTER_SPEC object(s) of a Resv message to the value, that
> > was received in the corresponding Path message. If the
> > incoming Resv message carries a Notify Request object then:
> >
> >  - If there is at least another incoming Resv message that
> > carries a Notify Request object and the LSR merges these Resv
> > messages into a single Resv message that is sent upstream,
> > the LSR MUST set the Notify node address in the Notify
> > Request object to its Router ID.
> >
> > - Else the LSR MUST propagate the Notify Request object
> > unchanged, in the Resv message that it sends upstream."
>
> See above comment
>

How about adding a bullet between these two bullets:

"- Else if the LSR sets the Sub-Group Originator ID in the outgoing Path
message, that corresponds to the received Resv message, to its own
address, the LSR MUST set the Notify node address in the Notify Request object to
its Router ID."



> >
> >
> > > > 2: Section 8.2 ResvConf
> > > >
> > > > Similar comment
> > > >
> > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> > > >    object(s) of a Resv message to the value, that was
> > received in the
> > > >    corresponding Path message. If any of the incoming
> > Resv messages
> > > >    corresponding to a single Path message carry a
> > RESV_CONFIRM object
> > > >    then the LSR MUST include a RESV_CONFIRM object in the
> > > > corresponding
> > > >    Resv message that it sends upstream and MUST set the receiver
> > > > address
> > > >    in the RESV_CONFIRM object to the value that was
> > received in the
> > > >    corresponding Resv message."
> > > >
> > > > Change to
> > > >
> > > > "
> > > >    A transit LSR sets the Sub-Group Originator ID in the
> > FILTER_SPEC
> > > >    object(s) of a Resv message to the value, that was
> > received in the
> > > >    corresponding Path message. If any of the incoming
> > Resv messages
> > > >    corresponding to a single Path message carry a
> > RESV_CONFIRM object
> > > >    then the LSR MUST include a RESV_CONFIRM object in the
> > > > corresponding
> > > >    Resv message that it sends upstream. If the sub-group
> > originator
> > > > ID is its own address then
> > > >    it MUST set the receiver address in the RESV_CONFIRM object to
> > > > this addresse, else it MUST
> > > >    propagate the object unchanged"
> > > >
> >
> > Shouldn't the transit LSR always set its own address in the
> > RESV_CONFIRM if it is merging multiple Resvs with
> > RESV_CONFIRM objects into a single Resv ? The current text is
> > not clear on this either.
>
> Same comment. Yes but IMO it should also do it when it changes the
> sub-group originator id (even with no Resv merge)?
>

That is correct.

> >
> > How about:
> >
> > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> > object(s) of a Resv message to the value that was received in
> > the corresponding Path message. If an incoming Resv message
> > corresponding to a single Path message carries a RESV_CONFIRM
> > object then the LSR MUST include a RESV_CONFIRM object in the
> > corresponding Resv message that it sends upstream and:
> >
> >  - If there is at least another incoming Resv message that
> > carries a RESV_CONFIRM object and the LSR merges these Resv
> > messages into a single Resv message that is sent upstream,
> > the LSR MUST set the receiver address in the RESV_CONFIRM
> > object to its Router ID.
> >
> > - Else the LSR MUST propagate the RESV_CONFIRM object
> > unchanged, in the Resv message that it sends upstream."
> >
>
> This also applies when the LSR changes the sub-group originator id without
> any Resv merge
>

How about adding a bullet in between these two bullets:

"- If the LSR sets the Sub-Group Originator ID in the outgoing Path
message, that corresponds to the received Resv message, to its own
address, the LSR MUST set the receiver address in the RESV_CONFIRM object
to its Router ID."

thanks,
rahul

> >
> > > >
> > > > 3: Section 14.2 Sub-group based reoptimization
> > > >
> > > > The new path may intersect the old path, this is a case
> > of rerouting
> > > > and this is not covered by remerge procedures as described in
> > > > section 18. Hence Transient Data duplication may occur during the
> > > > time between the Resv is received and the PathTear is
> > sent. To avoid
> > > > data duplication the branch node must not start
> > transmitting on the
> > > > new path before the old path has been torn down, but this
> > will lead
> > > > to transient packet loss.
> > > > This should be clearly mentionned here IMO.
> > > > Actually the only way to avoid both transient duplication and
> > > > transient packet loss is to rely on the global mb4b
> > procedure with a
> > > > new LSP id...
> > > >
> >
> > How about adding the following to this section:
> >
> > "Sub-Group based re-optimization may result in transient data
> > duplication as the new Path messages for a set of S2L
> > sub-LSPs may transit one or more nodes with the old Path
> > state for the same set of S2L sub-LSPs. "
>
> The proposed text addresses my point and is fine with me
>
> >
> >
> > > > 4: Section 18.1.1 Remerge Procedure
> > > >
> > > > The text says
> > > >    "The PathErr message MUST include all of the objects
> > > >    normally included in a PathErr message, as well as one
> > or more SUB-
> > > >    LSP objects from the set of sub-LSPs associated with
> > the matching
> > > >    P2MP LSP Path state.  A minimum of three SUB-LSP objects is
> > > >    RECOMMENDED. This will allow the node that caused the
> > re-merge to
> > > >    identify the outgoing Path state associated with the valid
> > > > portion of
> > > >    the P2MP LSP. The set of SUB-LSP objects in the received Path
> > > > message
> > > >    MUST also be included"
> > > >
> > > > And then:
> > > >
> > > >    "A node that receives a PathErr message that contains
> > the Error
> > > > Value
> > > >    "Routing Problem/P2MP Remerge Detected" MUST determine
> > if it is the
> > > >    node that created the re-merge case.  This is done by checking
> > > >    whether there is any intersection between the set of SUB-LSP
> > > > objects
> > > >    associated with the matching P2MP LSP Path state and
> > the set of
> > > > SUB-
> > > >    LSP objects in the received PathErr message.  If there
> > is, then the
> > > >    node created the re-merge case."
> > > >
> > > > There is an issue here. Actually there will always be an
> > > > intersection, because the PathErr includes the set of sub-lsp
> > > > objects in the received Path... IMO for this procedure to
> > work the
> > > > PathErr MUST only include sub-LSP objects associated with the
> > > > matching P2MP LSP state on the rermerge LSR and must not
> > include the
> > > > set of SUB-LSP objects in the received Path message.
> > > > By the way why are three objects recommended?
> > > >
> >
> > I believe this was clarified by John Drake offline and no
> > revisions were needed ?
>
> I will provide more comments in a following email.
>
> Best Regards,
>
> JL
>
> >
> > > >
> > > > Also find below some minor edits:
> > > >
> > > > Section 6.1
> > > >
> > > > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP
> > > >    SECONDARY_EXPLICIT_ROUTE> ]
> > > > Change to:
> > > > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP
> > > >    SECONDARY_RECORD_ROUTE> ]
> > > >
> >
> > Ok.
> >
> > > > Section 7.1
> > > > <S2L sub-LSP list> change to <S2L sub-LSP descriptor list>
> > > >
> >
> > Ok.
> >
> > > > Section 8.1.2
> > > >
> > > >  "If this LSR subsequently receives a corresponding
> > Notify message
> > > > from
> > > >    an upstream LSR than it MUST:
> > > >    - send a Notify message downstream toward the Notify
> > > >      node address that the LSR received in the Resv message.
> > > >    - process the sub-group fields of the FILTER_SPEC object in the
> > > >      received Notify message, and modify their values in
> > the Notify
> > > >      message that is forwarded to match the sub-group field values
> > > >      in the original Path message sent downstream by this LSR."
> > > >
> > > > Invert these two bullets
> > > >
> >
> > Ok.
> >
> > > > Section 8.2
> > > >
> > > > "If this LSR subsequently receives a corresponding
> > ResvConf message
> > > >    from an upstream LSR then it MUST:
> > > >    - send a ResvConf message downstream toward the
> > receiver address
> > > > that
> > > >      the LSR received in the RESV_CONFIRM object in the
> > Resv message.
> > > >    - process the sub-group fields of the FILTER_SPEC object in the
> > > >      received ResvConf message, and modify their values in the
> > > > ResvConf
> > > >      message that is forwarded to match the sub-group field values
> > > >      in the original Path message sent downstream by this LSR."
> > > >
> > > > Invert these two bullets
> > > >
> >
> > Ok.
> >
> > > > Section 11.2 last sentence
> > > >
> > > >    "Note the receiver of a ResvErr message is able to
> > identify the
> > > > errored outgoing Path [Change to: Resv]
> > > >    message, and outgoing interface, based on the Sub-Group fields
> > > >    received in the ResvErr message.
> > >
> >
> > Ok.
> >
> > >
> > > > Section 13
> > > >
> > > >  "A sender on a LAN uses a different label for sending
> > traffic to each
> > > >    node on the LAN that belongs to the P2MP LSP"
> > > >
> > > > This is not always the case, I would rather say
> > > >
> > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to
> > > > allocate a different label, in which case the sender has
> > to perform
> > > > replication"...
> > > >
> >
> > Actually the procedures in this document imply that a sender
> > on a LAN must do replication if there is more than one
> > downstream receiver. Upstream labels are required to avoid this.
> >
> > However I do realize that the first sentence is not entirely
> > accurate. How
> > about:
> >
> > "If there are multiple downstream LSRs on a LAN on a P2MP
> > LSP, a sender LSR on the LAN has to perform replication. A
> > separate copy of the data is unicast to each of the downstream LSRs"
> >
> >
> > > > Section 16
> > > >
> > > >    "Stitching and nesting
> > > >    considerations and procedures are described further in
> > [INT-REG]."
> > > >
> > > > Change to "Stitching and nesting
> > > >    considerations and procedures are described further in
> > > > [LSP-STITCH] and [RFC4206]."
> > > >
> > > > Section 17
> > > >
> > > > Infact => In fact
> > > >
> >
> > Ok.
> >
> > > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object => P2MP
> > > > LSP_IPv6 FILTER_SPEC object
> > > >
> >
> > Ok.
> >
> > > > Also some references need to be updated...
> > > >
> >
> > Will do that.
> >
> > Thanks for the detailed comments.
> >
> > rahul
> >
> > > > Best Regards,
> > > >
> > > > JL
> > > >
> > > > > -----Message d'origine-----
> > > > > De : owner-ccamp@ops.ietf.org
> > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa
> > > > Andersson Envoyé :
> > > > > samedi 13 mai 2006 12:48 À : mpls@ietf.org Cc : ccamp;
> > > > George Swallow;
> > > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill
> > > > > Fenner Objet : working group last call on
> > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > > > >
> > > > > Working Group,
> > > > >
> > > > > this initiates a two week working group last call on
> > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > > > >
> > > > > please send comments to the MPLS working group mailling list
> > > > > and/or working co-chairs.
> > > > >
> > > > > The last call ends eob May 28th.
> > > > >
> > > > > The ccamp mailing list copied as this is a work that has an
> > > > > overlap between the working groups.
> > > > >
> > > > > Loa and George
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Loa Andersson
> > > > >
> > > > > Principal Networking Architect
> > > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > > Kista, Sweden                      email:
> > loa.andersson@acreo.se
> > > > >                                            loa@pi.se
> > > > >
> > > > >
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mpls
> > >
> > >
> >
>
>

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls