Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05

[Eric Gray <[e-mail]>]

Zhenlong,

I'm not sure what you mean by a different behavior between
node ID and interface ID.  There is certainly a minimum
difference associated with what box-local entity it is
that is logically responsible for replying to a message.

But it seems as if we have converged in this discussion.

Thanks for taking the time to review and discuss the draft!

--
E

-----Original Message-----
From: Zhenlong Cui [mailto:[e-mail]]
Sent: Thursday, July 28, 2011 1:22 PM
To: Eric Gray; 'Sam Aldrin'
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
Importance: High

Hi, Eric

Small correction to the mail I just sent:

... "protocol redundancy is _not_ what I had in mind when I wrote my original mail." ...

Best
Zhenlong

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Zhenlong Cui
> Sent: Friday, July 29, 2011 2:04 AM
> To: 'Eric Gray'; 'Sam Aldrin'
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
>
> Hi Eric,
>
> Sorry, protocol redundancy is what I had in mind when I wrote my original mail.
>
> I didn't understand why to define a different behavior for "destination node identifier" and "destination interface
> identifier".
>
> In a P2MP scenario, an intermediate node may send multiple responses Which include different return codes (per-interface
> MIP case).
>
> I do understand the draft contains no such requirements for the for P2MP case.
> Essentially, the requestor receiving multiple responses which include different return code may not be a problem.
>
> Lastly, I think this issue might be discussed in the draft-farrel-mpls- tp-mip-mep-map, not here.
>
>
> Thanks for your response.
>
> > -----Original Message-----
> > From: Eric Gray [mailto:[e-mail]]
> > Sent: Thursday, July 28, 2011 12:45 AM
> > To: Zhenlong Cui; 'Sam Aldrin'
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> >
> > Not sure why you think the protocol redundancy is necessary,
> > or even a good idea.
> >
> > The DSMAP TLV as defined allows specification of an interface.
> >
> > Asking for a potentially new TLV that will also provide this
> > information in the event that one is unable to handle, read or
> > interpret the DSMAP TLV is pointless.  If one cannot use one
> > TLV, the chances are very good that one cannot use a newer one
> > either.
> >
> > -----Original Message-----
> > From: Zhenlong Cui [mailto:[e-mail]]
> > Sent: Wednesday, July 27, 2011 10:46 AM
> > To: 'Sam Aldrin'; Eric Gray
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> > Importance: High
> >
> > Hi Sam and Eric,
> >
> > Ok, I understand that the issue of unknown TLVs is outside the scope of this document.
> >
> > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV.
> > > > 1) Which return code to send when source/destination identifiersare wrong or drop the request.
> > > As said above, it should be dropped, if the source is unknown.
> >
> > OK, I think this is clear now:
> > - A responder will drop requests from an unknown source.
> > - A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.)
> >
> > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.
> > > Return code 5, dsmap mismatch. This is already defined in rfc4379.
> >
> > Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below.
> > The information collected MUST include identifiers related to the nodes and interfaces composing that route.
> >
> > I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity,
> > therefore they
> > should have the same behavior in the responder.
> >
> > So, my suggestions regarding these issues are as follows.
> > 1) It should be dropped, if the identifier of the DSMAP TLV is wrong.
> > 2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new TLV.
> >
> >
> > Best,
> > Zhenlong
> >
> > > -----Original Message-----
> > > From: Sam Aldrin [mailto:[e-mail]]
> > > Sent: Wednesday, July 27, 2011 6:29 AM
> > > To: Zhenlong Cui
> > > Cc: Eric Gray; [e-mail]; [e-mail]
> > > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> > >
> > > As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft.
> > > Having said that, please find responses inline.
> > >
> > > Sam
> > >
> > > Sent from my iPad
> > >
> > > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" <[e-mail]> wrote:
> > >
> > > > Hi Eric,
> > > >
> > > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security
> problem
> > > with
> > > > responding.
> > > > On the other hand, you say that you should send a reply when the request includes an unknown TLV.
> > > >
> > > Unknown source is not same as receiving malformed Tlv or unsupported tlv.
> > > > I think if the responder receives a request it checks the type of the TLV before it checks the identifiers.
> > > >
> > > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does
> > > the responder
> > > > have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it?
> > > If received from unknown source, most vendors drop the packet.
> > > >
> > > >
> > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV.
> > > > 1) Which return code to send when source/destination identifiers are wrong or drop the request.
> > > As said above, it should be dropped, if the source is unknown.
> > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.
> > > Return code 5, dsmap mismatch. This is already defined in rfc4379.
> > > >
> > > >
> > > > Best,
> > > > Zhenlong
> > > >
> > > >> -----Original Message-----
> > > >> From: Eric Gray [mailto:[e-mail]]
> > > >> Sent: Wednesday, July 27, 2011 12:56 AM
> > > >> To: Zhenlong Cui
> > > >> Cc: [e-mail]; [e-mail]
> > > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> > > >>
> > > >> Zhenlong,
> > > >>
> > > >> Q-1: See RFC 4379, where these regitry entries are derived from.
> > > >>     RFC 4379 sets up a number of registries - including the TLV
> > > >>     registry - and defines explicitly how to handle unknown TLV
> > > >>     types in section 3, in two very obscure paragraphs on page
> > > >>     10, just before section 3.1.
> > > >>
> > > >> Q-2: "ingress port" is not correct - thanks for spotting this
> > > >>     cut-and-paste duplication error.
> > > >>
> > > >> --
> > > >> Eric
> > > >>
> > > >> -----Original Message-----
> > > >> From: Zhenlong Cui [mailto:[e-mail]]
> > > >> Sent: Tuesday, July 12, 2011 5:20 AM
> > > >> To: [e-mail]; [e-mail]
> > > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> > > >>
> > > >> Dear Authors,
> > > >>
> > > >> Two questions regarding the idenfifiers TLV and DSMAP TLV.
> > > >>
> > > >> Question 1:
> > > >>>>> Which return code to send when identifiers are wrong (Malformed echo
> > > >>>>> request received?) or drop the packet.
> > > >>>>>
> > > >>>>> EG > Drop the packet, probably log the error, possibly run off
> > > >>>>> EG > screaming into the night.  What does one do when one gets
> > > >>>>> EG > something either not recognizably intended for one, or not
> > > >>>>> EG > from a source that one recognizes?  From a security point
> > > >>>>> EG > of view, we cannot require an implementation to reply to
> > > >>>>> EG > the requester in this case (this is an attack vector for
> > > >>>>> EG > all kinds of hate and discontent).  Nor can we forbid it.
> > > >>>>>
> > > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the
> requestor(One
> > > >> or
> > > >> more of the TLVs was not understood)? Can this way two answers be generated?
> > > >>
> > > >>
> > > >> Question 2:
> > > >> In section 2.1.1, Is below("ingress port") correct?
> > > >>
> > > >>   Egress IF_Num identifies the ingress port on the target node.  A
> > > >>   value of 0 indicates that the port is not part of the identifier.
> > > >>
> > > >>
> > > >> Best,
> > > >> zhenlong
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Rolf Winter
> > > >>> Sent: Monday, June 27, 2011 8:04 PM
> > > >>> To: Eric Gray; [e-mail]; [e-mail]
> > > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
> > > >>>
> > > >>> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379:
> > > >>>
> > > >>> Types are defined below; Length is the length of the Value field in
> > > >>> octets.  The Value field depends on the Type; it is zero padded to
> > > >>> align to a 4-octet boundary.
> > > >>>
> > > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV
> is
> > > determined
> > > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow
> your
> > > argument
> > > >>> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information
> > > >> is
> > > >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure
> > > >> of
> > > >>> each TLV to extract the value instead of applying the simple rule above.
> > > >>>
> > > >>>
> > > >>> Best,
> > > >>>
> > > >>> Rolf
> > > >>>
> > > >>>
> > > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Eric Gray [mailto:[e-mail]]
> > > >>>> Sent: Montag, 27. Juni 2011 12:42
> > > >>>> To: Rolf Winter; [e-mail]; draft-ietf-mpls-tp-on-demand-
> > > >>>> [e-mail]
> > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > > >>>> cv
> > > >>>>
> > > >>>> IMO, that would be a problem with RFC 4379.  Perhaps there is
> > > >>>> an errata?
> > > >>>>
> > > >>>> TLVs are meant to follow each other, where the beginning of the
> > > >>>> next TLV is determined by the length of the current TLV - hence
> > > >>>> it is not correct to specify any content as having any value at
> > > >>>> all if it is beyond the end of the TLV.
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From: Rolf Winter [mailto:[e-mail]]
> > > >>>> Sent: Monday, June 27, 2011 5:06 AM
> > > >>>> To: Eric Gray; [e-mail]; draft-ietf-mpls-tp-on-demand-
> > > >>>> [e-mail]
> > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > > >>>> cv
> > > >>>> Importance: High
> > > >>>>
> > > >>>> Hi Eric,
> > > >>>>
> > > >>>> just one more to follow up. You say:
> > > >>>>
> > > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long,
> > > >>>>> EG > even if the last two octets "Must be Zero").  The length of
> > > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made
> > > >>>>> EG > longer by the addition of the 2-word AGI.  Nice catch!
> > > >>>>
> > > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be
> > > >>>> included in the length of the sub-TLVs. Why are they included here?
> > > >>>>
> > > >>>> Best,
> > > >>>>
> > > >>>> Rolf
> > > >>>>
> > > >>>>
> > > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > > >>>> London W3 6BL | Registered in England 2832014
> > > >>>>
> > > >>>>
> > > >>>>>
> > > >>>>> EG > Apparently.
> > > >>>>>
> > > >>>>> Which return code to send when identifiers are wrong (Malformed echo
> > > >>>>> request received?) or drop the packet.
> > > >>>>>
> > > >>>>> EG > Drop the packet, probably log the error, possibly run off
> > > >>>>> EG > screaming into the night.  What does one do when one gets
> > > >>>>> EG > something either not recognizably intended for one, or not
> > > >>>>> EG > from a source that one recognizes?  From a security point
> > > >>>>> EG > of view, we cannot require an implementation to reply to
> > > >>>>> EG > the requester in this case (this is an attack vector for
> > > >>>>> EG > all kinds of hate and discontent).  Nor can we forbid it.
> > > >>>>>
> > > >>>>> Using the per-interface model and say the DSMAP TLV did not match the
> > > >>>>> ingress IF identifier, then should this request frame be dropped?
> > > >>>>> Should we reply to the requestor? Can this way two answers be
> > > >>>>> generated?
> > > >>>>>
> > > >>>>> Nit (section 2.1): s/mpls/MPLS/
> > > >>>>>
> > > >>>>> EG > Thanks.
> > > >>>>>
> > > >>>>>
> > > >>>>> Best,
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> Rolf
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > > >>>>> London W3 6BL | Registered in England 2832014
> > > >>>>>
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: [e-mail] [mailto:[e-mail]] On
> > > >>>> Behalf
> > > >>>>> Of
> > > >>>>>> Loa Andersson
> > > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01
> > > >>>>>> To: [e-mail]; [e-mail];
> > > >>>>> Ross
> > > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team
> > > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > > >>>> cv
> > > >>>>>>
> > > >>>>>> Working Group.
> > > >>>>>>
> > > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID
> > > >>>>>> after wg last call and published version -04 of the document.
> > > >>>>>>
> > > >>>>>> A document detailing how the comments have been addressed will be
> > > >>>>>> found at:
> > > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls
> > > >>>>>>
> > > >>>>>> This is to start a working group call to verify that all comments
> > > >>>>>> been adequately addressed. Please send your comments to the
> > > >>>>>> mpls working group mailing list before June 24th.
> > > >>>>>>
> > > >>>>>> Loa
> > > >>>>>> on behalf of the MPLS wg co-chairs
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Loa Andersson                         email:
> > > >>>>> [e-mail]
> > > >>>>>> Sr Strategy and Standards Manager            [e-mail]
> > > >>>>>> Ericsson Inc                          phone: [phone]
> > > >>>>>>                                              [phone]
> > > >>>>>> _______________________________________________
> > > >>>>>> mpls mailing list
> > > >>>>>> [e-mail]
> > > >>>>>> https://www.ietf.org/mailman/listinfo/mpls
> > > >>>>> _______________________________________________
> > > >>>>> mpls mailing list
> > > >>>>> [e-mail]
> > > >>>>> https://www.ietf.org/mailman/listinfo/mpls
> > > >>> _______________________________________________
> > > >>> mpls mailing list
> > > >>> [e-mail]
> > > >>> https://www.ietf.org/mailman/listinfo/mpls
> > > >
> > > >
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/mpls
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls