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

["Zhenlong Cui" <[e-mail]>]

Hi Eric,

I have some questions for DSMAP TLV again.
I'm just like to clarify the behavior for the responder, it's not for protocol redundancy :)


1) In sec 2.1
------
  ... IF_Num information for both Requester and Responder interfaces, as well as multipath information is included in the format and
MAY be present ...
------

 Is the above explanation correct? 
 I think the IF_Num is just for the Responder, as sec 2.1.1.


2) In sec 2.1.1
-----
   Ingress IF_Num identifies the ingress port on the target node.  A
   value of 0 indicates that the port is not part of the identifier.

   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.
-----

I think we have four cases for this TLV as follows.
a) Both of the Ingress IF_Num and Egress IF_Num are 0.
b) Only Ingress IF_Num is 0.
c) Only Engress IF_Num is 0.
d) Both of the Ingress IF_Num and Egress IF_Num are not equal to 0.


So, I think we need to clarify the behavior for the responder in each case.
Following examples just is my considered opinion, could you confirm it?

In the case a):
 Should be processed by Per-node model.
 
In the case b):
 Should be replied by Egress interface, because the request frame is targeted for Egress interfase.

In the case c):
 Should be replied by Ingress interface, because the request frame is targeted for Ingress interfase.

In the case d):
 Should be discarded, because this frame is wrong.

Best,
Zhenlong

> -----Original Message-----
> From: Eric Gray [mailto:[e-mail]]
> Sent: Friday, July 29, 2011 2:39 AM
> To: Zhenlong Cui; 'Sam Aldrin'
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> 
> 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